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A System for Processing Healthcare Related Event Information for Use 
in Scheduling Performance of Tasks 

This is a non-provisional application of provisional application serial 
No. 60/318,664 by S. Brandt et al. filed September 12, 2001. 

Field of the Invention 

This invention concerns a system and user interface supporting 
scheduling a workflow process comprising a set of tasks to be performed by at least 
one individual to support healthcare delivery. 

Background of the Invention 

Modern healthcare requires the concurrent provision of services by 
many health-care workers to many patients. In order to accomplish this, healthcare 
delivery has been organized into specialized departments such as nursing, laboratory, 
and radiology departments. Each department has responsibility for accomplishing its 
particular, often specialized, subset of tasks. Unfortunately, this has resulted in 
fragmented patient care and sub-optimal healthcare operations. A single healthcare 
process such as the ordering and administration of a medication, requires the 
participation of many health-care workers, possibly across many departments, and is 
therefore fraught with opportunities for error and delay. 

Clinical and healthcare information systems provide a computerized 
interface for health-care workers to perform individual tasks. However, these systems 
typically have limited capability to manage the sequence of tasks involved in 
healthcare processes. This is particularly true when the processes require the 
involvement of multiple health-care workers. Workflow management systems are 
designed to manage complex processes that include individual work steps performed 
by multiple workers and systems. They allow the customized configuration of these 
processes, as well as continuous monitoring and management while the processes are 
in progress. In order to optimally employ a workflow management system in 
healthcare, it is desirable that the system support configuration of a workflow (i.e. 
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determination of a sequence and schedule of tasks to be performed by one or more 
individuals) at a local level. Such a local level may be within a facility where the 
workflow is to be implemented, for example. 

Existing healthcare or clinical information systems provide user 
interfaces for performing individual healthcare tasks and viewing and recording of 
information. This includes, for example, results reporting, goods and services 
ordering, clinical and nursing care documentation, and financial or operational data 
capture. However, existing systems are typically task oriented, and provide interfaces 
for individuals to accomplish specific tasks. As such they fail to provide the flexible 
and comprehensive user interfaces and systems needed to support the adequate 
management of clinical care and documentation processes that involve multiple users, 
and which occur over an extended period of time, and are amenable to reengineering. 
M= A system according to invention principles addresses these deficiencies and 
jif derivative deficiencies. Specifically the disclosed system supports creation, initiation 
m and modification of workflow processes that sequence tasks to be performed by 
Jf healthcare personnel and also supports the monitoring and management of the tasks 
Fh and of their progress until their successful completion. 

p Summary of Invention 

A system and user interface integrates and processes event associated 
O messages affecting healthcare delivered to a patient and supports creation, initiation 
fij and modification of currently operating workflow processes involving processing of 
event messages. A method for processing an event representing a change in 
circumstances potentially affecting healthcare delivered to a patient involves 
receiving a message identifying an event potentially affecting healthcare delivered to 
a patient. Particular tasks to be performed are determined and scheduled to be 
performed by at least one individual in response to occurrence of the identified event. 

In a feature of the invention, the method involves searching a database 
containing records indicating active process instances to identify active process 
instances of a target process to be replaced by a process comprising the particular 
tasks. 

In another feature of the invention, a parameter associated with an 
event is stored at a location available for access by multiple different process task 
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sequences. 

BRIEF DESCRIPTION OF THE DRAWING 

Figure 1 shows an existing healthcare or clinical information system 
for invoking actions in external systems. 

Figure 2 shows a system that allows healthcare enterprises to create 
and configure workflow processes (comprising task sequences to be performed) 
responsive to events generated from a Healthcare Information System (HIS), 
according to invention principles. 

Mi Figure 3 shows a user interface display window for use indicating 

■~ ? events and associated parameters that are usable in altering workflow processes 
J comprising scheduled task sequences, according to invention principles. 

m 

f t; Figure 4 shows a process flowchart for processing an event for use in 

=P replacing one or more tasks of a scheduled workflow process, according to invention 

q principles. 

Figure 5 shows a process flowchart for processing an event and 

q associated parameters for use in replacing a scheduled workflow process, according 

fU to invention principles. 

Figure 6 shows a workflow and event management system responsive 
to events generated by other workflow processes and responsive to events external to 
an HIS, according to invention principles. 

Figure 7 shows a currently operating Healthcare Information System 
(HIS) workflow process responsive to a predetermined event generated by another 
workflow process. 



Figure 8 shows a system for processing an event indication affecting a 
currently operating instance of a Healthcare Information System (HIS) workflow 
process, according to invention principles. 
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Detailed Description of the Drawing 

Figure 1 shows an existing healthcare or clinical information system 
for invoking actions in external systems. In such a system, messages identifying 
events or actions taken in a Healthcare Information System (HIS) 12 (perhaps 
involving storage unit 14) in response to user actions 10, are communicated to 
external systems 17-21 through an interface engine 15. An event as used herein is an 
action or occurrence representing a change in circumstances potentially affecting 
healthcare delivered to a patient. An event message identifying such an event may be 
generated due to action by healthcare personnel, by an operating process (perhaps for 
influencing other operating processes), by a non-healthcare system such as an 
administrative application (perhaps involving financial transaction information), or by 
M= patient monitoring equipment. An event message may also be generated by other 
devices for example: patient locator or proximity devices, and medical equipment 
if! such as IV pumps. Interface engine 15 may comprise a workflow processing 
application or other application supporting communication with external systems 17- 
pi 21. A workflow as used herein comprises a sequence of tasks or operations that are 
* scheduled for performance, or are being performed, by one or more entities including 
O individuals, groups of individuals, or personnel assigned to perform particular 
H ! functions or roles. External systems 17-21 comprise a laboratory 17, pharmacy 18 and 
fj financial application (such as for patient service tracking and billing) 21, for example, 
Q but may also encompass a broader range of systems including any system with which 
tli jjjg j2 performs a transaction or data exchange. Further Healthcare Information 
System (HIS) 12 may comprise other types of information system such as a Clinical 
Information System or Critical Care Information System or another Information 
system. Further, in other embodiments HIS 12 may include non-healthcare 
information systems such as financial information systems provided that such a 
system involves performing a sequence of tasks that is susceptible to modification as 
a result of occurrence of an event. 

The existing systems workflow processing function exemplified in the 
unit 15 function of Figure 1 has a number of deficiencies. These include limited 
flexibility in configuring workflow processes and limited capability for creating 
workflow processes that may be dynamically re-configured in response to events. 
Existing workflow management systems are typically limited in the flexibility they 
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allow in configuring workflow processes and in allocating codes for identifying 
processes and events, for example. This is insufficient for healthcare applications in 
which a healthcare enterprise HIS system supplied by one vendor is oblivious of 
workflow process configurations implemented using workflow management 
application software provided by a different vendor. In addition, existing workflow 
management systems typically assume that individual work processes are 
autonomous and are unaffected by other running processes. In contrast, real 
healthcare processes constantly affect each other. For example, a patient being taken 
to radiology for a diagnostic study interferes with the administration of intravenous 
medication in the patient's room. Further, the complexity of modern healthcare 
enterprises means that a healthcare workflow process may need to be responsive to 
multiple different healthcare events, and also that a single event may impact multiple 
1=5= different concurrently operating healthcare processes. For example, an order to 
2 discharge a patient from a hospital may have multiple workflow processes associated 
|j| with it, such as management of discharge medications, cancellation of dietary orders, 
and initialization of a discharge billing process. Further, a single workflow 
Jl management process to cancel and to re-issue dietary orders may occur as a 
=F consequence of a discharge order, an order of "NPO" or nothing by mouth, or the 
p transfer of a patient to surgery, for example. This implies a more sophisticated 
mechanism is required for invoking workflow processes than existing workflow 
management systems currently support. The disclosed system supports creation and 
Q configuration of healthcare processes that interact with each other and respond to 
iU changes and events originating in other processes. 

The disclosed system and user interface integrates and processes event 
associated messages affecting healthcare delivered to a patient. The system provides a 
means for ensuring that messages are generated upon occurrence of selected events 
and for forwarding those generated messages to a workflow management system. The 
system also provides a method and user interface for linking a configured workflow 
process to a healthcare event so that a selected workflow process adapts upon 
occurrence of the event. For this purpose the system advantageously categorizes and 
filters events generated by an HIS to ensure that the events affecting the configured 
workflow process, or other healthcare workflow processes, are forwarded to the 
workflow management system. The filter thereby excludes a potentially large volume 
of event items of no consequence to system workflow processes. This significantly 
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reduces the workload involved. Upon occurrence and detection of a user selected 
particular event, the system further allows a user to predetermine which one of 
multiple different workflow processes is implemented. Thereby, at user discretion, 
occurrence of an event may result in a default workflow process or another different 
workflow process being implemented. Further, the selected workflow process may 
also be further adapted upon occurrence of additional events. This enables 
conventional workflow processes to be employed as default processes or allows 
dynamically adaptive workflow processes to be implemented or allows both types of 
process to operate in parallel. This supports flexible workflow management and 
enables a considerable degree of flexibility in workflow process implementation and 
re-engineering upon healthcare system alteration or modification. 

Figure 2 shows a system that allows healthcare enterprises to create 
H- and configure workflow processes (comprising task sequences to be performed) and 
to link the created workflow processes to events generated from HIS 12. In response 
If! to user actions 10, HIS 12 using storage 14 generates event messages and 
ZZ communicates them to event monitor 25 (in event processor 28). The event messages 
01 include event identifiers and metadata that identify user actions and other occurrences 
*P associated with healthcare delivery and support that take place in a healthcare 
f% enterprise and potentially affect healthcare delivered to a patient. Event messages 

M provided by HIS 12 may identify user orders, documentation, and reports. Examples 

iy, 

■ %l include such items as: a physician order for "Gentamicin 120 mg IV Stat then 80 mg 
13 every 8 hours", a nursing documentation of "2 cm area of redness on the patient's left 
m lateral heel", or a microbiology report of "methacillin resistant staph aureus" cultured 
from a skin lesion of a newborn in the level one nursery. Such orders and 
observations require action by healthcare personnel and are advantageously processed 
by the Figure 2 system. 

In a conventional system a Gentamicin order, for example, is simply 
encoded in Health Level 7 (HL 7) format and forwarded to a pharmacy system for 
preparation of the drug. In contrast, the system of Figure 2 creates and manages a 
workflow that accommodates the healthcare implications and consequences of such 
an order. The order intends a sequence of at least 7 events, for example, including the 
mixing of the medication, its transport to the patient's room, the insertion of an IV 
line if required, the infusion of the drug, nursing oversight to ensure that the drug 
infuses properly, nursing documentation of the infusion, and adjustment of 
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subsequent doses to maintain the appropriate interval. In the case of receiving nursing 
documentation or a microbiology report event messages, the Figure 2 system 
implements a consistent set of workflow processes for responding to the nurse 
observations and the outcome of the microbiology test. In the first case, the Figure 2 
system initiates a process including a scheduled task to protect the patient from skin 
breakdown and in the second case, the Figure 2 system initiates a process including a 
scheduled task to implement an isolation procedure within a nursery. 

The event messages also include parameter values and other metadata 
that is to be provided to a particular workflow process application in response to 
occurrence of a corresponding particular event. In the case of a drug order event, for 
example, the parameters may include a patient identifier, a drug identifier, drug 
strength, method of administering the drug, and dosing information. In the case of a 
nursing documentation of skin findings report event, the parameters may include a 
patient identifier, a finding identifier, descriptors, and site identifiers. Event monitor 
25 categorizes and filters the received event messages and forwards those messages 
that are associated with registered workflow processes. Other event messages that are 
not associated with registered workflow processes are excluded. For this purpose 
event monitor 25 maintains a database including a map associating events, event 
identifiers and parameter identifiers with workflow processes. The map is used in 
determining parameter values and other data that is to be provided to a particular 
workflow process application in response to occurrence of a corresponding particular 
event. 

In response to receiving an event message, event monitor 25 examines 
its map to determine whether a workflow process is associated with the event 
identified by the event identifier in the received message. If the identified event is 
associated with a particular workflow process (decision 34 of Figure 2), event 
monitor 25 examines any parameters associated with the identified event and 
conveyed in the received event message from HIS 12. Specifically, monitor 25 
determines if received event parameter values match predetermined criteria 
associated with the corresponding event. The predetermined criteria are specified 
during an event registration process during which a workflow process is associated 
with one or more identified events and associated event parameters. Thereby a 
workflow process is associated with one or more events and related event parameter 
values. If event monitor 25, using its map, finds that no workflow process is 
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associated with the identified event (decision 32 of Figure 2), it disregards the event 
message and returns a message to HIS 12 instructing HIS 12 to proceed with default 
processing. Such default processing may involve HIS 12 communicating via 
messages 43 with external systems 17-21 through an interface engine 19 in support of 
a default workflow process in similar fashion to that described in connection with 
Figure 1, for example. 

Event monitor 25 performs further operations if it determines in 
decision 34 that the identified event is associated with a particular workflow process 
and the received event parameter values are within a predetermined range. 
Specifically, monitor 25 determines from predetermined user selection information 
whether a default process is to be replaced by a workflow managed process that is 
invoked as a consequence of the event. If it is not to be replaced, monitor 25 returns a 
|=& message to HIS 12 instructing HIS 12 to proceed with the default workflow 

y processing. If it is to be replaced HIS 12 surrenders processing to event monitor 25 

U 

m and the particular workflow process associated with the identified event by the 

I s * monitor 25 internal map is implemented. Further, event monitor 25 provides rules 

■fTS 

g=. engine 30 with the event identifier and associated event parameter values for use in 
M implementing the particular workflow process. 

In addition, monitor 25 also determines from predetermined user 
fa* selection information whether there is an executable procedure (e.g. a script file) 
r : associated with the particular workflow process. Such a procedure may incorporate 
Q logic determining how an event associated workflow process is initiated or processed, 
^ for example. If there is such an associated procedure, monitor 25 also provides the 
procedure to rules engine 30 for execution. Alternatively the procedure may be pre- 
stored in rules engine 30, in which case monitor 25 commands engine 30 to initiate 
execution of the procedure. Rules engine 30 uses the information and commands 
received from monitor 25 to call the Workflow Management System 36 and instruct it 
to implement the event associated particular workflow process 31. It does this by 
creating and initiating a copy (an instance) of the desired event associated particular 
workflow process. In a complex system a workflow process may be implemented 
multiple times (i.e. as multiple instances) for different patients, for example. 
Therefore, process copies are made of a template process and the copies (instances) 
are the processes that are actually implemented. The multiple workflow process 
instances may or may not be in concurrent operation. The implemented workflow 
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process may also be configured to communicate with users and other systems (e.g. 
laboratory 17, pharmacy 18 and financial system 21) via interface engine 19. 

Figure 3 shows a user interface display window for use indicating 
events, associated parameters, executable procedures and other data that are usable in 
initiating or altering workflow processes comprising scheduled task sequences. The 
menu display image of Figure 3 is derived by HIS 12 (Figure 2) using an Extensible 
Markup Language (XML) document though in other embodiments the user interface 
of Figure 3 may be derived based on other language files such as HTML, SGML etc.. 
The Figure 3 user interface includes prompt element 630 that presents a list of 
workflow processes available for selection. This enables a user to associate a 
workflow process such as Gentamicin Management selected via prompt element 630 
with events such as a Gentamicin order 603 selected from hierarchically arranged 
events via prompt element 600. The user interface also enables a user to associate the 
selected workflow process (Gentamicin Management) with event parameters derived 
from HIS 12 (Figure 2) and an executable procedure to be conveyed to the workflow 
process management routine upon occurrence of the selected event (here an order for 
Gentamicin). The event parameters from HIS 12 are mapped into corresponding 
parameters of the associated workflow process. The event parameters and executable 
procedure are selected for association with the selected workflow process via prompt 
elements 611 and 633 respectively. The Figure 3 user interface enables an order with 
a parameter value associated with patient discharge to be used to initiate a patient 
discharge procedure, for example. As another example, a pharmacy order for 
Gentamicin IV may be used to initiate an aminoglycoside infusion process. 

Particular event parameters such as the patient's identifier number 
(PTID) 612, dose (for example, 1 ml or 2 tablets) 620, time (for example, every 8 
hours) 618, route (for example, intravenous) 616, and strength (for example, 80 
mg/ml or 500 mg) 614 are selected via prompt element 611 which also indicates the 
corresponding identification label employed by the workflow process. The 
Gentamicin workflow process parameter label PTID 610 corresponds to the same 
label PTID 612 employed by HIS 12, for example. The workflow and HIS labels need 
not be the same in other cases and prompt element 611 advantageously presents to a 
user the parameter mapping of an HIS label to a corresponding workflow process 
label and enables a user to verify that the mapping is correct and to amend the 
mapping if required. Further, a user is able to select via selection item 625 whether a 
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default workflow process is to be replaced by the event associated workflow process 
selected via prompt element 630. Selection of item 625 results in replacement of a 
scheduled default workflow process (or in another embodiment, particular identified 
tasks of the default workflow process) with the event associated workflow process 
selected via prompt element 630. Non-selection of item 625 results in the default 
workflow process being supplemented by the event associated workflow process. 
Such supplementing of a default workflow process may take the form of the event 
associated workflow process running entirely in addition to the default process or 
may comprise the addition of some task steps to the default process. Further, although 
not shown in the Figure 3 user interface (to preserve drawing clarity), a user is able to 
select event parameter values for use as selection criteria for process initiation. For 
example, a workflow process can be registered for Ampicillin . Thereby a workflow 
M process may be initiated if Ampicillin is ordered and can be configured to apply only 
^ if the administration route is intravenous. In addition, although not shown to preserve 
yF| drawing clarity, the user interface of Figure 3 may include an image element for 
jf; prompting a user to select a default process that is to be modified or replaced and to 
ffl associate this selected default process with an event associated workflow process. In 
P another embodiment (and also not shown), the Figure 3 user interface also allows a 
p user to view the selected default process tasks and to select particular tasks to be 
hk modified by the event associated workflow process. 

rj Figure 4 shows a process flowchart for use by event processor 28 

p (Figure 2) for replacing one or more tasks of a scheduled workflow process with 
Hi event associated tasks. In step 303 after the start at step 300, event processor 28 
receives a message (e.g. from HIS 12 Figure 2) identifying occurrence of an event. 
Processor 28 applies predetermined rules in step 308 to determine particular tasks to 
be performed in response to the identified event. Event processor 28 examines 
predetermined user selected information identifying those of the particular tasks that 
are to be added to an existing workflow process and those of the particular tasks that 
are to be substituted for existing tasks in the existing workflow process. The 
identified additional tasks are added to the existing workflow process in step 310 and 
the. identified substitute tasks are substituted for the existing tasks in step 313. 
Further, the particular tasks are scheduled for performance as part of the existing 
workflow process by an entity such as an individual, group of individuals or 
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personnel assigned to a role or another arrangement of personnel in step 315 and the 
process of Figure 4 ends at step 319. 

Figure 5 shows a process flowchart for processing an event and 
associated parameters for use in replacing a scheduled workflow process with an 
event associated workflow process. In step 403 after the start at step 400 event 
processor 28 (Figure 2) receives one or more messages (e.g. from HIS 12) identifying 
occurrence of an event as well as an associated parameter, process and instance of the 
process and also including a value of the event associated parameter. As previously 
explained an instance of a process is a copy of a workflow process and may comprise 
a particular use of the process for a specific patient, for example. Processor 28 applies 
predetermined rules in step 405 to interpret the identified event to select in step 409 a 
particular process (comprising predetermined tasks) from a plurality of predetermined 
processes. In step 411 processor 28 creates an instance of the selected predetermined 
process and provides this instance with the parameter values previously received in 
IP step 403. Processor 28 in step 414 schedules performance of the selected workflow 
rf process instance by an entity (e.g. at least one individual) to replace a scheduled 

iff'S 

p, workflow process. The process of Figure 5 is complete at step 417. 
=p As an example, the Figure 2 system is considered in operation in 

p conjunction with a configured IV antibiotic infusion workflow process. The user 
I* interface described in connection with Figure 3 is employed to associate the antibiotic 
J 5 ! infusion workflow process with events comprising orders of a medication which have 
q a drug type that is an antibiotic and a route that is Intravenous. This workflow process 
Til is designated to replace a default system process (e.g. following selection of icon 625 
of Figure 3). Therefore, in response to a physician placing an order for Gentamicin 
120 mg IV for patient 1234, HIS 12 (Figure 2) generates an event message indicating 
that Patient 1234 is the subject of a drug order for drug name "Gentamicin" 
specifically, drug type "aminoglycoside antibiotic", dose strength 120 mg , route IV. 
Event processor 28 receives the event message and determines that it has one or more 
subscribed predefined processes and that at least one of them is to replace the default 
system workflow process. Event processor 28 communicates a return message to HIS 
12 to indicate that HIS 12 is not to proceed with the default workflow process but 
instead processor 28 is to implement a substitute a workflow process previously 
associated with the event via the Figure 3 user interface. This return message is 
incorporated in the event acknowledgment message but in other embodiments 
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multiple separate messages may be used. Event processor 28 maps data parameters 
received in the event message from HIS 12 to corresponding parameters required by 
the event associated substitute workflow process. In addition the event processor 
initiates creation and scheduling of processing of an instance of the substitute 
workflow process using rules engine 30 and workflow management system 36 
(Figure 2). 

In a further example, the user interface described in connection with 
Figure 3 is employed to associate an IV infusion workflow process with an "IV 
infusion failure" event for a particular patient identifier and a particular drug. Upon 
failure of a smart IV infusion pump to infuse the particular drug because of air in the 
line, the pump communicates an event message indicating "IV infusion failure" to 
event processor 28. The event message also includes pump identifier, patient 
identifier and drug parameter information derived from storage associated with the 
smart pump device. Event processor 28 determines that it has several workflow 
processes associated with the "IV infusion failure" event and accompanying 
particular received patient identifier and drug identifier. Thereupon, processor 28 
initiates a call to the running instances of the event associated workflow processes 
with the particular received patient identifier and drug identifier using parameters 
derived from the IV infusion workflow process involving the "IV infusion failure" 
event. The notified workflow process modifies its behavior based upon the 
notification, and includes the scheduling of alerting a nurse to have the problem 
corrected. 

Figure 6 shows a workflow and event management system responsive 
to events 46 generated by other workflow processes and responsive to events 47 
external to an HIS. This provides enhanced capabilities for managing healthcare 
workflow. Thereby, for example, medication IV pumps, upon completion of infusion, 
may communicate an event message (including predetermined patient and medication 
identifiers stored by the pump) to event monitor 25. In response, event monitor 25 
initiates an event associated workflow process that efficiently implements a 
predetermined healthcare regimen following infusion, and/or notifies running process 
instances of the occurrence of events for which they have registered interest. 
Similarly, patients may be provided with location or proximity detector badges 
enabling event messages to be generated upon a change in location of a patient and 
further promoting efficient care. In addition, in the Figure 6 system, a first workflow 
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process is configurable to generate an event message and communicate it to event 
monitor 25 for modifying a different second (or more) workflow process. Such an 
event message may include parameters identifying change in a patient location, 
patient status or nurse availability, for example. 

The inventors have recognized that a problem arises in workflow 
management systems that constrain particular parameters or status indications to be 
exclusively associated with particular workflow process instances. Further that there 
is an advantage in employing global event associated parameters. Such a global event 
parameter may be associated with, and accessed by, more than one workflow process 
and process instance. This prevents the problem of having multiple workflow 
processes that interact potentially using a common event associated parameter with 
different incompatible values. Such a problem arises, for example, if a parameter 
indicating a location of a specific patient, set within a first running workflow process, 
is different to another location indication for the same patient maintained in a second 
process. This may occur for a variety of reasons such as if the patient location 
indication is updated at different intervals by the first and second processes or by use 
of a different location identification scheme by the first and second processes. The 
use of an individual global event parameter accessible from multiple running 
workflow processes prevents this problem. Thereby, a patient global event parameter 
indicating location (or other information item), stored at a single point, may be 
advantageously updated and accessed from multiple workflow processes based on a 
common patient identifier, for example. 

In response to receiving an event message 46 or 47 and in similar 
fashion to the system of Figure 2, event monitor 25 (Figure 6) examines an internal 
map to determine whether a workflow process is associated with an event identified 
by an event identifier. If the identified event is associated with a particular workflow 
process (decision 34), it is determined whether the event associated workflow process 
is to be implemented. For this purpose event monitor 25 determines whether any 
received event parameter values or globally accessible event parameter values 
identified in the received event messages 46 or 47 are within an acceptable 
predetermined range. If the received parameters are acceptable and the event 
associated workflow process is to be implemented, event monitor 25 provides rules 
engine 30 with the event identifier and associated event parameter (including global 
parameter) values for use in implementing the particular workflow process. Rules 



2001P16949US01 



engine 30 determines whether other event associated workflow process 
implementation pre-conditions are satisfied and support implementation of the event 
associated workflow process. Such pre-conditions include conditions derived from an 
executable procedure associated with the event associated workflow process, for 
example. The operation of the remainder of the Figure 6 system is the same as for the 
system described in connection with Figure 2. Specifically, rules engine 30 uses the 
information received from monitor 25 to call the Workflow Management System 36 
and instruct it to implement the event associated particular workflow process 31. The 
implemented workflow process may also communicate with users and other systems 
(e.g. laboratory 17, pharmacy 18 and financial system 21) via interface engine 19. 

Figure 7 shows a currently operating Healthcare Information System 
(HIS) workflow process responsive to a predetermined event generated by another 
M. workflow process. It is known for workflow management systems to employ within a 
g workflow process (comprising tasks 800-815) a special workflow task termed a 
j|j "process event step" 807 that may be directly referenced and initiated within a 
J* currently operating workflow process. In order to initiate special event step 807, a 
gj calling application provides the workflow process with a process identifier, a specific 
=p process instance identifier and an event step identifier (e.g., identifying step 807). 

Further, such a process event step may be used to initiate a task sequence path 
C (comprising tasks 807, 809, 810, 804 and 815) that is different to the normal 
-== workflow process task sequence path (comprising tasks 800, 803, 804 and 815). 
Q Thereby, providing a modified workflow process. 

IU However, the inventors have recognized that existing workflow 

management systems are limited in the use of the process event step feature. This is 
because process instance identifiers are generated when copies (instances) of 
workflow processes are dynamically generated. They are not known in advance. 
Known systems typically require that in order to call such a process event step, the 
calling parameters (process identifier, a specific process instance identifier and an 
event step identifier) are predetermined and stored at the time they are associated with 
events generated from an HIS or other workflow processes. Consequently, 
subsequently dynamically created copies (instances) of a workflow process, including 
a process event step, have different unrecognized process instance identifiers. 
Therefore, such subsequently created process instances do not respond to event 
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messages and are not initiated upon occurrence of an event associated with the 
original process. The system of Figure 8 addresses this deficiency. 

Figure 8 shows a system for processing an event indication affecting a 
currently operating instance of a Healthcare Information System (HIS) workflow 
process. In the Figure 8 system, upon initiation of an instance of workflow process 31 
event monitor 25 is provided with its process identifier, its specific process instance 
identifier and its process event step identifier (or multiple process event step 
identifiers if they exist). Upon receiving an event message, event monitor 25 
determines that the event identified by the received message is associated with 
workflow process 31 (decision 34). Further, event monitor 25 identifies any currently 
operating or scheduled instances of process 31 (decision 905). This is determinable 
since all instance identifiers of corresponding instances of process 31 have been 
la provided to monitor 25 upon their initiation, or monitor 25 can query Workflow 

O Management System 36 for this information when needed. Event monitor 25 also 

O 

yS determines which of the identified currently operating instances of the identified 
H> event associated workflow process 31 are to be implemented based on criteria 
Jjj previously explained in connection with Figure 2. Thereupon, event monitor 25 
=p provides rules engine 30 with the event identifier and associated event parameter 
(including global parameter) values for use in implementing the particular workflow 
§=* process 31 instances. Rules engine 30 uses the information received from monitor 25 
J* to validate the process initiation and instruct Workflow Management System 36 to 
p implement the event associated particular workflow process 31 instances. 
?y As an example, if a dietary workflow process is associated with an 

event comprising a "nothing by mouth" order, event monitor 25 determines whether 
there is a running instance of the dietary workflow process for the same patient that is 
the subject of the "nothing by mouth" order. It does this using an internal database 
tracking operating process instances and associated process, instance and process 
event step identifiers as well as associated event parameters, executable procedures 
and other event related data. Event monitor 25 uses the identifiers in instructing rules 
engine 30 to call an appropriate process event step within the identified operating 
process instance. This event processing method provides a flexible, efficient and 
dynamically alterable workflow process management system. Using this system, 
workflow processes incorporating one or more process event steps may be devised 
that may be dynamically selected in response to an array of different events (internal 
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and external to an HIS) occurring in a healthcare environment. For example, using 
multiple process event steps and such an event processing system an individual 
operating workflow process may comprise multiple different scheduled task 
sequences that are each selectable in response to occurrence of corresponding 
particular healthcare events. As a result operating workflow processes are 
dynamically modifiable in response to events occurring in the course of a patient 
treatment or diagnosis regimen. This contributes to providing an efficient flexible and 
responsive healthcare system. 

The architectures and processes presented in Figures 1-8 are not 
exclusive. Other architectures and processes may also be derived in accordance with 
the principles of the invention to accomplish the same objectives. Further, the 
inventive principles may be advantageously employed in any workflow processing 
system responsive to events and is not limited to use in the healthcare field. 



